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Abstract 


This document defines a method to encrypt a file transfer using the 
FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", 
(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October 
1997) [1]. This method will use the Key Exchange Algorithm (KEA) to 
give mutual authentication and establish the data encryption keys. 
SKIPJACK is used to encrypt file data and the FTP command channel. 


1.0 Introduction 


The File Transfer Protocol (FTP) provides no protocol security except 
for a user authentication password which is transmitted in the clear. 
In addition, the protocol does not protect the file transfer session 
beyond the original authentication phase. 


The Internet Engineering Task Force (IETF) Common Authentication 
Technology (CAT) Working Group has proposed security extensions to 
FTP. These extensions allow the protocol to use more flexible 
security schemes, and in particular allows for various levels of 
protection for the FTP command and data connections. This document 
describes a profile for the FTP Security Extensions by which these 
mechanisms may be provisioned using the Key Exchange Algorithm (KEA) 
in conjunction with the SKIPJACK symmetric encryption algorithm. 
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FTP Security Extensions [1] provides: 


* user authentication -- augmenting the normal password 
mechanism; 

* server authentication -- normally done in conjunction with user 
authentication; 

* session parameter negotiation -- in particular, encryption keys 


and attributes; 


* command connection protection -- integrity, confidentiality, or 
both; 

* data transfer protection -- same as for command connection 
protection. 


In order to support the above security services, the two FTP entities 
negotiate a mechanism. This process is open-ended and completes when 
both entities agree on an acceptable mechanism or when the initiating 
party (always the client) is unable to suggest an agreeable 
mechanism. Once the entities agree upon a mechanism, they may 
commence authentication and/or parameter negotiation. 


Authentication and parameter negotiation occur within an unbounded 
series of exchanges. At the completion of the exchanges, the 
entities will either be authenticated (unilateral or mutually), and 
may, additionally, be ready to protect FTP commands and data. 


Following the exchanges, the entities negotiate the size of the 
buffers they will use in protecting the commands and data that 
follow. This process is accomplished in two steps: the client offers 
a suggested buffer size and the server may either refuse it, counter 
it, or accept it. 


At this point, the entities may issue protected commands within the 
bounds of the parameters negotiated through the security exchanges. 
Protected commands are issued by applying the protection services 
required to the normal commands and Base64 encoding the results. The 
encoded results are sent as the data field within a ENC (integrity 
and confidentiality) command. Base64 is an encoding for mapping 
binary data onto a textual character set that is able to pass through 
most 7-bit systems without loss. The server sends back responses in 
new result codes which allow the identical protections and Base64 
encoding to be applied to the results. Protection of the data 
transfers can be specified via the PROT command which supports the 
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same protections as those afforded the other FTP commands. PROT 
commands may be sent on a transfer-by-transfer basis, however, the 
session parameters may not be changed within a session. 


2.0 Key Exchange Algorithm (KEA) Profile 


This paper profiles KEA with SKIPJACK to achieve certain security 
services when used in conjunction with the FTP Security Extensions 
framework. FTP entities may use KEA to give mutual authentication 
and establish data encryption keys. We specify a simple token format 
and set of exchanges to deliver these services. Functions that may 
be performed by the Fortezza Crypto Card. 


The reader should be familiar with the extensions in order to 
understand the protocol steps that follow. In the context of the FTP 
Security Extensions, we suggest the usage of KEA with SKIPJACK for 
authentication, integrity, and confidentiality. 


A client may mutually authenticate with a server. What follows are 
the protocol steps necessary to perform KEA authentication under the 
FTP Security Extensions framework. Where failure modes are 
encountered, the return codes follow those specified in the 


Extensions. They are not enumerated in this document as they are 
invariant among the mechanisms used. The certificates are ASN.1 
encoded. 


The exchanges detailed below presume a working knowledge of the FTP 
Security Extensions. The notation for concatenation is " || ". 
Decryption of encrypted data and certification path validation is 
implicitly assumed, but is not shown. 


Client Server 
AUTH KEA-SKIPJACK --> 
<-- 334 ADAT=Base64( Certb || Rb ) 
ADAT Base64( Certa || Ra || 
WMEK || Iv || Encrypt ( 
Label-Type || Label-Length | | 
Label-List || pad || Icv ) ) --> 


<-- 235 ADAT=Base64( IV ) 


The server and client certificates contain KEA public keys. The 
client and server use KEA to generate a shared SKIPJACK symmetric 
key, called the TEK. The client uses the random number generator to 
create a second SKIPJACK key, called the MEK. The MEK is wrapped in 
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the TEK for transfer to the server. An initialization vector (IV) 
associated with the MEK is generated by the client and transferred to 
the server. A list of security labels that the client wants to use 
for this FTP session may be transferred to the server encrypted in 
the MEK. As shown in Figure 2, the security label data is formatted 
as a one octet type value, a four octet label length, the security 
label list, padding, followed by an eight octet integrity check value 
(ICV). Figure 3 lists the label types. If the label type is absent 
(value of zero length), then the label size must be zero. 


In order to ensure that the length of the plain text is a multiple of 
the cryptographic block size, padding shall be performed as follows. 
The input to the SKIPJACK CBC encryption process shall be padded to a 
multiple of 8 octets. Let n be the length in octets of the input. 
Pad the input by appending 8 - (n mod 8) octets to the end of the 
message, each having the value 8 - (n mod 8), the number of octets 
being added. In hexadecimal, he possible pad strings are: 01, 0202, 
030303, 04040404, 0505050505, 060606060606, 07070707070707, and 
0808080808080808. All input is padded with 1 to 8 octets to produce 
a multiple of 8 octets in length. This pad technique is used 
whenever SKIPJACK CBC encryption is performed. 


An ICV is calculated over the plaintext security label and padding. 
The ICV algorithm used is the 32-bit one’s complement addition of 
each 32-bit block followed by 32 zero bits. This ICV technique is 
used in conjunction with SKIPJACK CBC encryption to provide data 
integrity. 


Label Type 1 Octet 
Label Length 4 octets 
Label List variable length 
Pad 1 to 8 octets 
ICV 8 octets 
Figure 2 
Label Type Label Syntax Reference 
0 Absent Not applicable 
ak MSP SDN.701[2] 
2-299 Reserved for Future Use To Be Determined 
Figure 3 
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FTP command channel operations are now confidentiality protected. To 
provide integrity, the command sequence number, padding, and ICV are 
appended to each command prior to encryption. 


Sequence integrity is provided by using a 16-bit sequence number 
which is incremented for each command. The sequence number is 
initialized with the least significant 16-bits of Ra. The server 
response will include the same sequence number as the client command. 


An ICV is calculated over the individual commands (including the 


carriage return and line feed required to terminate commands), the 
sequence number, and pad. 


Client Server 


ENC Baseé4 (Encrypt ("PBSZ 65535" 


|| sEQ || paa || Icv )) --> 
<-- 632 Base64 (Encrypt (" a | | 
SEQ || pad || Icv) 
ENC Baseé4 (Encrypt ("USER yee" 
|| sEQ || paa || Icv)) --> 
<-- 632 Base64 (Encrypt (" A | | 
SEQ || pad || Icv) 
ENC Baseé4 (Encrypt ("PASS 
fortezza" || SEQ || 
pad || Icv)) --> 


<-- 631 Base64(Sign("230") ) 


After decryption, both parties verifying the integrity of the PBSZ 
commands by checking for the expected sequence number and correct 
ICV. The correct SKIPJACK key calculation, ICV checking, and the 
validation of the certificates containing the KEA public keys 
provides mutual identification and authentication. 


Client Server 


ENC Baseé4 (Encrypt ("PROT P" | | 
SEQ || pad || Icv)) --> 
<-- 632 Baseé4 (Encrypt ("200" 
|| pad || rcv 


w — 
So 
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At this point, files may be sent or received with encryption and 
integrity services in use. If encryption is used, then the first 
buffer will contain the token followed by enough encrypted file 
octets to completely fill the buffer (unless the file is too short to 
fill the buffer). Subsequent buffers contain only encrypted file 
octets. All buffers are completely full except the final buffer. 


ENC Baseé4 (Encrypt ( 
("RETR foo.bar") 
SEQ || pad || Icv 


| 
| 
v 


<-- 632 Base64 (Encrypt ("150" 
SEQ || pad || Icv 


as 
<~ — 


Plaintext Token IV 24 octets 

WMEK 12 octets 

Hashvalue 20 octets 

IV 24 octets 

Label Type 1 octets 

Label Length 4 octets 

Label Label Length octets 
Pad 1 to 8 octets 

ICV 8 octets 

Figure 7 


2.1 Pre-encrypted File Support 


In order to support both on-the-fly encryption and pre-encrypted 
files, a token is defined for carrying a file encryption key (FEK). 
To prevent truncation and ensure file integrity, the token also 
includes a hash computed on the complete file. The token also 
contains the security label associate with the file. This FEK is 
wrapped in the session TEK. The token is encrypted in the session 
TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped 
FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type, 
a 4 octet label length, a variable length label value, a one to 8 
octet pad, and an 8 octet ICV. The first 24 octets of the token are 
the plaintext IV used to encrypt the remainder of the token. The 
token requires its own encryption IV because it is transmitted across 
the data channel, not the command channel, and ordering between the 
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3. 


4. 


Dis 


channels cannot be guaranteed. Storage of precomputed keys and 
hashes for files in the file system is a local implementation matter; 
however, it is suggested that if a file is pre-encrypted, then the 
FEK be wrapped in a local storage key. When the file is needed, the 
FEK is unwrapped using the local storage key, and then rewrapped in 
the session TEK. Figure 8 shows the assembled token. 


Plaintext Token IV 24 octets 
Wrapped FEK 12 octets 
Hashvalue 20 octets 
IV 24 octets 
Label Type 1 octet 
Label Length 4 octets 
Label Label Length octets 
Pad 1 to 8 octets 
ICV 8 octets 
Figure 8 


0 Table of Key Terminology 


In order to clarify the usage of various keys in this protocol, 
Figure 9 summarizes key types and their usage: 


Key Type Usage 

TEK Encryption of token at the beginning of 
each file, also wraps the MEK and the FEK 

MEK Encryption of command channel 

FEK Encryption of the file itself (may be 


done out of scope of FTP) 


0 Security Considerations 


This entire memo is about security mechanisms. For KEA to provide 
the authentication and key management discussed, the implementation 
must protect the private key from disclosure. For SKIPJACK to 
provide the confidentiality discussed, the implementation must 
protect the shared symmetric keys from disclosure. 
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8.0 Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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